home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / letters_fj / text0004.txt < prev    next >
Encoding:
Text File  |  1995-10-04  |  5.8 KB  |  140 lines
  1. Hi again,
  2.  
  3. (I needed a break from work...)
  4.  
  5. > There seems to be growing support for the atari in your country.
  6.  
  7. At least there are a few people doing _something_. I don't know about the
  8. growing part, though.
  9.  
  10. > OK. I think you're right in saying that evrything not running at the same
  11. > time as the game can be written in C: file managing, and so on. But do you
  12.  
  13. Well, mostly yes.
  14.  
  15. > really find doom's monsters so intelligent that they can't be programmed in
  16. > assembler? I have really had the impression that they just tracked you, saw
  17. > you, and shot you. The tracking part is the difficult part, but not so much,
  18.  
  19. Well, they don't seem quite that stupid to me. They don't act smart in any
  20. way, but their motion patterns, especially when they're far away or when
  21. there are many of them, often seem to be non-random, but also non-obvious.
  22.  
  23. > >The Falcon is not fast, but with a little DSP help it's not _that_ slow.
  24. > No, it's not that slow, but we want our program to be as fast as possible.
  25.  
  26. Naturally. Have you given any thought to what should be put on the DSP?
  27. Both sound and drawing code would likely benefit tremendously, but it might
  28. not be very easy to handle both.
  29. Perhaps AI and sound?
  30.  
  31. Is the BSP tree too large to keep in the DSP RAM?
  32.  
  33. > We want some smoothness, and I really think we will need all the machine
  34. > cycles we can save.
  35.  
  36. We'll just have to wait and see how things come along. Since we have the
  37. dview source, I think it would be a good idea to start there. If, after a
  38. bit of work, things don't look good, we could come up with something new.
  39.  
  40. Have you found any other sources, by the way?
  41.  
  42. > >GCC would be hard pressed to compile a single line.
  43. > Yes, but GCC takes a lot of memory. Anyway, I have to admit I develop a lot
  44. > of personal short programs in C, but have never done a very very large
  45.  
  46. MGIF sure is very large (600-700kbyte sources excluding libraries last time
  47. I looked), but no single file is much longer than 30k.
  48. Still I can't compile all of it with full optimization without VM (or of
  49. course by throwing away NVDI, Thing, WINX etc).
  50.  
  51. With VM I have about 400kbyte left of 1Mbyte normal RAM and just about all
  52. the alternate RAM I could ever want. I've not found any use for over 16M so
  53. far, though.
  54.  
  55. > program. I use an old turbo C and have never had any memory problem. For
  56. > assembly language, I use DevPack.
  57.  
  58. Yes, I guess that might be alright.
  59.  
  60. > >We'd have to find someone well versed in AI to do that kind of thing, I
  61. > >think. Smartness is bad enough without making it variable.
  62. > What I meant was that you could block some abilities, such as finding a non
  63. > direct path, or anticipating your moves, etc.
  64. > Don't you think the AI involved is very specialized?
  65.  
  66. Probably not as it stands in DOOM now, but I was thinking more of controlling
  67. how _good_ a path to find and how _well_ to anticipate moves. Just blocking
  68. specific things would make the whole thing a lot easier, I believe.
  69.  
  70. I don't think either of those things is very easy at all to do.
  71.  
  72. Have you read about the Jaguar game 'Battle Sphere' on rec.games.video.atari?
  73. One of the programmers of that recently mentioned how he had to _lower_ the
  74. amount of defense smartness for the opposing ships.
  75. They were too good to be killed by a mere human!
  76.  
  77. > >Anyway, there are levels in DOOM where I think it's almost necessary to
  78. > >make use of the specific behaviour of the monsters. If they were to run
  79. > >around obstacles in new ways, things could get difficult.
  80. > Do you have a specific example? I don't recall such a case. Do you remember,
  81.  
  82. On the level I'm on now (22 I think) for example, there are a whole bunch of
  83. caco-demons in a star-shaped chamber. In the middle is a rocket launcher
  84. IIRC. Anyway, if those things had followed me only half intelligently I
  85. don't think I'd have had a chance (I'm still getting killed, though  :-(  )
  86.  
  87. I remember being able to do some of the other levels earlier by knowing what
  88. way the monsters take out of a room for example.
  89.  
  90. A friend of mine once designed a level of his own where he intended the
  91. monsters to come up behind you as you were slaughtering those in front.
  92. He never made it work, presumably because the monsters wouldn't do what he
  93. wanted them to.
  94. The level would've been _quite_ difficult if it had worked!
  95.  
  96. > though, how in Dungeon Master, you had to draw skeletons on some buttons for
  97. > them to open a door?
  98. > I loved this game!
  99.  
  100. I've only played it for an hour or so. I've never been fond of RPGs.
  101.  
  102. > >For real directional sound you'd have to phase shift an appropriate amount,
  103. > >which I don't think is trivial (I've never tried, though).
  104. > The math are easy: the phase is the time difference between the arrival of
  105. > the signal on the two ears of the listener. So the phase shift is just
  106. > proportional to the difference between two distances. So you just have to
  107. > compute two distances before playing each sound. The technical aspect
  108. > shouldn't be too difficult to work out. IMHO.
  109.  
  110. Yes, you're right, it shouldn't. But since I've never seen (heard) a game,
  111. and perhaps not even a record, do that, I'm not so sure.
  112. It would be interesting to test...
  113.  
  114. > Well, in fact, I found that substation's sound was very dirty. I don't see
  115.  
  116. I've not tried it yet.
  117.  
  118. > what is so great about this program anyway. (hope you're not a friend of the
  119. > authors ;)
  120.  
  121. It didn't seem the least bit great to me either, but then I've never tried
  122. doing anything like that before.
  123. And no, I do not know any of the authors.
  124.  
  125. > >Ooops, my train is leaving in a couple of minutes!
  126. > Hehe!
  127.  
  128. I missed it actually. That's the first time for _very_ long I've done that.
  129. Fortunately there was another one about 70 minutes later.
  130.  
  131. Regards,
  132. Johan
  133.  
  134. -- 
  135.   Chalmers University   | Why are these |  e-mail:   d8klojo@dtek.chalmers.se
  136.      of Technology      |  .signatures  |            rand@cd.chalmers.se
  137.                         | so hard to do |  www/ftp:  rand.thn.htu.se
  138.    Gothenburg, Sweden   |     well?     |            (MGIFv5 and QLem)
  139.  
  140.